RAGのGが必要か不要かに関する一考察

まとめ

RAGにおける回答生成が必要か不要かに関して考えました。業務面・技術面・環境面を整理して判断するのが良さそうです。また、情報検索のみで良いのかという点について、回答生成以外の要素も含めて考えてみました。

はじめに

新規事業部 山本です。

ChatGPT（OpenAI API）をはじめとしたAIの言語モデル（Large Language Model：以下、LLM）を使用して、チャットボットを構築するケースが増えています。通常、LLMが学習したときのデータに含まれている内容以外に関する質問には回答ができません。そのため、例えば社内システムに関するチャットボットを作成しようとしても、素のLLMでは質問に対してわからないという回答や異なる知識に基づいた回答が（当然ながら）得られてしまいます。

この問題を解決する方法として、Retrieval Augmented Generation（以下、RAG）という手法がよく使用されます。RAGでは、ユーザからの質問に回答するために必要そうな内容が書かれた文章を検索し、その文章をLLMへの入力（プロンプト）に付け加えて渡すことで、ユーザが欲しい情報に関して回答させることができます。

以前の記事では、新たにRAGの方式を考えてシステムを構築したり、システムを試用した結果の分析を行いました。

Google Cloud Enterprise SearchとRetrieveReadCompose方式RAGを利用して社内公式情報を全部質問できるようにしてみた | DevelopersIO

RAGを使った社内情報を回答できる生成AIボットで業務効率化してみた | DevelopersIO

この記事では、上記の記事で使っているRAGについて、たまに見かける「RAGのGは不要ではないか」つまり「生成部分は不要で、検索のみで十分」という考えについて、自分なりに考えてみた必要か不要かを判断する観点やその基準について、大まかに記載します。（他の方の考え方を批判するものや、自分の考えた正しいことを主張するものではありません。読んだ方の判断材料が増えれば幸いです。）

前提・説明

まず、RAGについて説明します。RAGとは、Retrieval Augmented Generation（検索拡張生成）の略です。生成AIにドキュメントに基づく回答や文書生成をさせたいときに、以下の手順で実行します。

• Retrieval：質問・指示に関連するテキストを抽出ために、ドキュメントを検索する
• Generation：検索結果のドキュメントと質問・指示をプロンプトにまとめ、LLMに回答・文章を生成させる

「RAGのGが不要」というのは、この回答生成=Generation部分がなくてもよく、検索=Retrieve部分のみで十分であるという考えです。（異なる考えの方もいるかもしれません）

おそらくこの背景には、LLMをベースにした新しい検索手法（埋め込みベクトルによるセマンティック検索や、マルチモーダル検索）も加わり、従来よりも検索の精度が向上したり機能が増えている、ということが挙げられると思われます。

生成が不要な理由・場面

こうした「生成がいらない」と言われる理由や状況としては、以下のように業務面・環境面・技術面があるように思われます。

業務面：そもそも不要な場合

検索だけで費用対効果が高いユースケース

ドキュメントの量が膨大で、検索だけで時間がかかっているケースが当てはまります。例えば、数千件～数万件と対象とする場合には生成機能がなくても効果がありそうです。こうしたケースでは、PoC段階では検索だけ試す、ということも選択肢として十分考えられます。

生成がそこまで求められないユースケース

士業のような、間違いがあった際の影響度が大きい場合、文章生成の機能があっても毎回専門家が文書を作り直すことになり、必要性が薄いと思われます。生成される文章の質が相当上がらない限り費用対効果は低く、基本的に不要と判断されると思われます。

環境面：人手での効率が良くカバーできてる場合

検索だけで十分な環境があるケース

検索ができれば後はユーザ側でドキュメントを読んで、欲しい情報を手にいれられる場合、生成がなくても目的を達成できます。以下の挙げるような条件が満たされていて、ユーザが効率的に作業できる場合、生成の必要性自体は薄そうです。

• ドキュメント構成がわかりやすく整備されている

  全体構成・ページ設計・フローなどがわかりやすく、ユーザがどこの情報があるのか見つけるのに時間や労力がかからない。プロジェクトのチケットなど、ドキュメントの形式が決まっている場合も当てはまるでしょう。

• 文章自体がわかりやすい

  書かれているテキスト自体がわかりやすい。例えば、前提や用語が説明されていたり、手続きなどの条件分岐がわかりやすく書かれていると、ユーザが読み解きやすくなります。

• ユーザのリテラシー・読解能力が高い、時間に余裕がある

  ドキュメントだけでなく、ユーザ側も要素になると思われます。ドキュメント構成や前提・コンテキスト・用語を元々理解していたり、難しいドキュメントでも読み解けたり、そうしたことをするための時間の余裕があるユーザが多い場合なら、生成機能の方が効率が悪いかもしれません。

技術面：必要だけど技術が追いつかない場合

生成の精度・レイテンシー・コストが不十分で採用にいたらないケース

（生成機能は必要であるものの）生成される文章の質が低いこと、処理にかかる時間が長い・料金が高いことを理由に、採用にいたらないケースも考えられます。LLMのモデル本体の機能・性能だけでなく、それを使う周辺部分（処理方式、ドキュメントの質、ユーザへの見せ方、UI・UXの設計など）もまだ発展途上にあるため、現状では満足できる結果がでないこともありえます。

生成が必要な理由・場面

上記の内容を逆にすると、生成が必要そうな場面がわかりそうです。

業務面：業務的に生成機能が求められる場合

検索単体だけでは導入する意味が薄いケース

例えば、業務に関する問い合わせへの対応などは、回答者は業務内容を把握しているため、回答の文章を考えて書く作業に時間がかかります。こうしたケースでは生成の方がむしろ必要です。

生成に多大な時間がかかってるケース

検索・生成ともに時間がかかっているが、特に生成の方が割合が大きい場合。こうしたケースだと検索の効率化をしても全体としての効率化は低く、生成の方が重点的に効率化するべきです。

環境面：人手でカバーできない or かなり負担が強いられている場合

ドキュメント構成がわかりにくい場合、文章自体がわかりにくい場合、ユーザのリテラシー・読解能力が高くない、時間に余裕がない場合など、上記の逆のケースです。往々にしてあり得ると思います。特に、問い合わせに対応する方は、他の業務を担当していて空き時間などに対応されているので、対応かかる時間を減らしたいと思われていることが多いです。

また、こうしたケースだと回答を得るまでに時間がかかってしまいますが、生成機能があれば、一次回答をすぐに出すことができ、問い合わせた側がスムーズに作業を進められるというメリットがあります。

技術面：性能・機能が要件を満たす場合

生成の精度・レイテンシー・コストが十分なケース

生成が絶対に必要というわけでなくても、各要件を満たすようであれば、生成まで含めて導入して試すということはあると思います。

また、今後LLMのモデル本体が改良されることや、周辺要素も成熟が進んで来ることを考えると、現状では不足していても、将来、要件を満たすようになることもあるでしょう。

必要なのは「生成」だけか

「情報を検索して提示するのみで良いのか」は一考の余地があると思います。

ベクトル検索で欲しい情報が得られないときの問題点と改良方法を考えてみた | DevelopersIO

以前、上記のページで記載したのですが、やっぱり人に対応してもらうと、楽だな、ありがたいなと感じることがあります。こうした要素には、以下のようなものがあると考えられます。（以下は問い合わせ対応の場合ですが、同様のことが人とのやり取りには含まれていると思います）

• 複雑なドキュメントを情報を、わかりやすい形に直して回答してくれる
• さまざまなドキュメントをまたいだ情報を教えてくれる
• 補足情報も加えてくれる
• こちらのことを察して回答してくれる
• そもそも質問が間違っていることを指摘してくれる

こうした部分まで対応できると、業務も効率化されるのに加え、ストレスの少ない利便性が高いシステムになり、世の中が大きく変わりそうです。情報検索のみを対象としていると、こうした可能性を見過ごしてしまいそうです。ここまで実現できるか不透明ですが、今後の展望も含めて、人とのコンピュータの対話として捉え、情報検索だけにとどまらない仕組みを検討してみると良いのではないかと思います。